Banks and other institutions may use computerized systems to manage information. A computerized system may include one or more software components, associated interfaces, databases and supporting hardware. Components may comprise a plurality of applications. Various ones of the components may require information from, or supply information to, others of the components, where the components may belong either to a common computerized system or distinct computerized systems.
An example occurs in banks. One software component of a computerized system of a bank might be used for managing loans made by the bank—e.g., taking loan applications, administering payments and the like. Another software component of a computerized system of the bank might relate to collateral management. The collateral management component would typically need information from the loan management component, and vice versa, for example to determine whether a loan applicant had provided enough security for a given loan to be approved. Further, both the loan management component and the collateral management component might supply information, from time to time, to an analyzer component that used the information to perform calculations, generate statistics and perform regulatory reporting.
Sharing of information between computerized systems as described in the foregoing need not be confined to a single institution such as a bank. Various independent entities (e.g., businesses, government agencies) need to be able to obtain the information of other independent entities, and to provide information to other independent entities. There could be a one-way flow of information between entities, or a two-way flow. That is, an entity might supply information to another, but not receive information from the other; or might receive information from another but not supply it to the other. On the other hand, two entities might mutually exchange information.
In the various computerized systems described in the preceding, in many cases the supplying of information and the obtaining of information needs to be possible on demand in order for the businesses and other institutions served by the systems to operate properly. For example, in a bank, a loan could be initially approved, but then the requested amount of the loan might increase. In this event, the loan management component would need to determine whether the value of the collateral securing the loan was enough to secure the increased loan amount. Therefore, the loan management component would need to obtain the value of the collateral from the collateral management component. Similarly, the collateral management component would need to be informed about the increased loan amount.
Moreover, different entities need different information at different times. For example, a bank analyzer component might need historical information about loans stretching back weeks or months in order to perform its functions. On the other hand, a collateral management component might never need anything more than the most current “snapshot” of a loan status.
Computerized systems are known for handling information flow as described above. Such systems may abstract suppliers of information as “senders,” and requesters or receivers of information as “receivers.” In view of the differing needs of receivers, one challenge for the systems associated with on-demand service is ensuring that a given receiver gets the kind of information it needs, when it needs it. The challenge is presented largely by the fact that information is continually changing and being added to, while computer processing and data storage capabilities are finite.
By way of illustration, consider again the example of a bank. Information about a given account might change a number of times over the course of a day, week or month. For a first receiver of information about the account, only current information might be needed. On the other hand, a second receiver of information about the account might need to know the information for one or more points in the past. Still a third receiver might need to know information about the account for one or more points in the past different from the points that the second receiver is interested in.
There might be many more such changing accounts in the bank, and many more receivers with varying needs for information about the accounts. One straightforward approach to meeting the needs of all the receivers might be to simply maintain independent copies of the information as needed for each receiver. However, this approach is clearly unworkable because of the huge demands it would place on data storage and processing capacity.
Accordingly, it is known to only supply and receive changes in the information. That is, assuming an initial or base information set, only changes to the base information set, such as modifications, additions or deletions are supplied to interested receivers. In the case of a bank loan, for example, the base information set might include such data as an account number, a borrower's name and address, and initial conditions, such as an initial interest rate. Then, the base information set might be changed, for example, by a modification of the initial interest rate, the addition or deletion of participants in the loan, the occurrence of an early termination, or the like. Interested receivers, assuming they already have all or some the base information set, can keep up-to-date in accordance with their respective needs by being informed only of the changes.
Existing techniques for propagating such changes include a “push” technique and a “pull” technique. In a push technique, when a change occurs in a sender's information, the sender sends the change information, without being requested to, to all known interested receivers at substantially the same time as the change occurs, or at some later, previously arranged or convenient time. In a pull technique, a receiver requests information when it wants it, and a sender returns information in response to the request.
However, there are disadvantages associated with known techniques. One disadvantage is that a receiver that uses a pull technique (a “pull receiver”) cannot obtain reliable historical data. This is because a pull receiver may not know when information that it is interested in has changed, and consequently may not request the change information. Thus, if the information changes again before the pull receiver requests the earlier change information, that earlier change information may be lost for the pull receiver. While it would be possible for a sender to push change information to all interested receivers whenever change occurs, this would not be an acceptable arrangement for most pull receivers, since most pull receivers are only able to process information at times of their choosing. Further, the arrangement would in general place excessive demands on and lower the performance of the associated computer systems. Another alternative would be for the sender to save copies of all pre-change data in the event a pull receiver later wants historical data. However, this alternative also has disadvantages, since, along lines discussed earlier, it would be costly in terms of data processing and storage capacity, and there may be cases when there is no actual need for the saved data.